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Abstract 

ua  develop  an  event-based  modal  to  spacify 
formally  tha  bahavior  (tha  axtamal  viav)  and 
tha  structure  (the  intarnal  view)  of  distributed 
systems .  Both  control-related  and  data-ralatad 
properties  of  distributed  systems  are  specified 
using  two  fundamental  relationships  among 
events)  the  'happens  before"  relation,  repre¬ 
senting  time  order)  and  the  "enabling"  relation, 
representing  causality.  No  assumption  about  tha 
existence  of  a  global  clock  Is  made  in  the 
specifications. 

The  correctness  of  a  design  can  be  proved 
before  implementation  by  checking  the  consis¬ 
tency  between  the  behavior  specification  and  tha 
structura  specification  of  a  system.  Important 
properties  of  concurrent  systems  such  as  "mutual 
exclusion,"  "concurrency,"  and  other  "safety" 
and  "livenase"  properties  can  be  specified  and 
verified. 

1.  Introduction 

Computations  of  distributed  systems  are  ex¬ 
tremely  difficult  tc  specify  and  verify  using 
traditional  techniques  because  the  systems  are 
inherently  concurrent,  asynchronous  and  nondetar- 
ministic.  Furthermore,  computing  nodes  in  a 
distributed  system  may  be  highly  independent  of 
each  other,  and  the  entire  system  may  lack  an 
accurate  global  clock. 

In  this  paper,  we  develop  an  event-based  model 
to  specify  formally  tha  behavior  (the  external 
view)  and  tha  structure  (the  Intarnal  view)  of 
distributed  systems.  Both  control-related  and 
date-related  properties  of  distributed  systems  are 
specified  using  two  fundamental  relationships 
among  events)  the  "happens  before"  relation,  repre¬ 
senting  time  order;  and  the  "enabling"  relation, 
representing  causality.  No  assumption  about  tha 
existence  of  a  global  clock  is  eada  in  tha  speci¬ 
fications. 

The  correctness  of  a  design  can  be  proved 
before  implementation  by  checking  tha  consistency 
between  the  behavior  specification  and  structura 
specification  of  a  system.  laportant  properties 
of  concurrent  systems  such  as  "mutual  exclusion," 
"concurrency,"  and  other  “safety"  and  "liveness" 
properties  can  be  specified  and  verified. 


Moreover,  since  tha  specification  technique 
defines  the  orthogonal  properties  of  a  system  sep¬ 
arately,  each  of  them  can  then  be  verified  inde¬ 
pendently.  Thus,  the  proof  technique  avoids  tha 
exponential  state-explosion  problem  found  in  state- 
machine  specification  techniques. 

2 ,  Conceptual  Modelling 

A  distributed  system  may  be  described  from 
two  different  points  of  view.  From  a  designer's 
viewpoint,  it  consists  of  local  processes  inter¬ 
acting  with  users  and  communicating  among  them¬ 
selves  via  the  service  of  communication  stadium. 

Each  local  process  can  be  described  by  tha  oper¬ 
ations  responding  to  user's  commands,  messages 
from  other  processes  or  internal  clocks.  The 
structura  is  depicted  in  Figure  1. 

From  a  user's  viewpoint,  a  distributed  system 
is  a  black  box,  or  a  shared  server  with  only  the 
interfaces  visible  to  him,  as  shown  in  Figure  2. 

In  this  case,  except  for  performance  issues,  there 
is  no  difference  in  functionality  between  a  dis¬ 
tributed  system  and  a  centralized  one.  The  only 
things  interesting  are  what  kind  of  messages  or 
events  may  happen  in  the  interfaces  and  What  are 
the  relationships  among  the  messages  or  the  events. 
We  call  such  kind  of  interface  description  of 
a  system,  its  bahavior  specification. 

3.  The  Event  Model 

We  consider  the  behavior  of  a  system  to  be 
a  set  of  computation  histories  characterized  by 
"events."  The  siodel  in  which  our  specification  is 
based  upon,  therefore,  consists  of  events  and 
their  relationships. 

3.1  Event 

An  event  is  an  instantaneous ,  atomic  stats 
transition  in  the  computation  history  of  a  system. 
Examples  of  events  are  the  sending,  tha  receiving, 
and  the  processing  of  messages.  By  "instantaneous" 
we  mean  an  event  takes  zero-time  to  happen.  By 
"atomic"  we  mean  an  event  happens  completely  or 
not  at  all. 

3.2  Event  Relationships 
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3.2,1  Time  Ordering:  '->' 

In  describing  the  tine  ordering  among  event*, 
a  system-wide  reliable  clock  is  usually  assumed 
to  order  totally  the  events  in  a  centralized  sys¬ 
tem.  Unfortunately,  the  assumption  of  the  exis¬ 
tence  of  such  a  global  clock  is  too  strong  in 
describing  the  computation  of  a  distributed  sys¬ 
tem  which  is  inherently  concurrent,  asynchronous 
and  nondeterministic.  Theoretically  speaking,  in 
soma  extreme  case,  it  is  impossible  to  order  two 
events  totally  when  they  happen  in  two  geographi¬ 
cally  separated  places.  Practically  speaking, 
implementing  such  a  global  clock  is  quite  expen¬ 
sive  and  unnecessary  in  a  distributed  system  having 
highly  autonomous  computing  nodes.  He  give  up  the 
global  clock  assumption  and  come  out  with  a  partial 
ordering  relation-the  “preceding'  relation  de¬ 
noted  by  '->',  to  represent  the  time  concept 
(GRE77,  LAM78J. 

The  interpretation  of  '-> '  as  a  time  ordering 
means  that,  if  el  and  «2  are  events  in  a  system 
and  el->e2,  then  el  happens  before  e2  by  any 
measure  of  time.  To  understand  the  meaning  of 
'-»',  let  us  look  into  Figure  3.  Each  vertical 
line  in  Figure  3  represents  the  computation  his¬ 
tory  of  a  (sequential)  “process.*  By  a  “process" 
we  moan,  an  autonomous  computing  node  having  its 
own  "local*  clock)  different  processes  may  use 
different  time  scales.  The  dots  denote  events 
and  the  dotted  line  between  events  denote  mes¬ 
sages.  The  relation  '  has  the  following  prop¬ 
erties  i 

(1)  If  el  and  e2  are  events  in  the  same  process, 
and  el  comes  before  a2,  then  el-»e2  (e.g. 
pl-»p2  in  Figure  3) ; 

(2)  If  el  is  the  sending  event  of  a  massage  by  one 
process  and  e2  is  the  receiving  event  of  the 
message  by  another  process,  then  by  the  law 

of  'causality',  el->e2  (e.g.  pl->q2  in  Figure 
3)  > 

(3)  (Transitivity  property)  If  el-»e2  and  e2->e3 
then  el->e3  (e.g.  pl->g3  in  Figure  3) i 

(4)  Uxxeflexlvity  property)  For  every  event  a, 

*  <e-»e) i 

(5)  (Antisymmetry  property)  If  el->e2  then 
-  (e2-»el) 

3.2.2  Concurrency 

Two  distinct  events,  say  el  and  *2 ,  are  con¬ 
current  if.  *  (el->e2)  and  *  (e2-»el)  and  denoted  by 
el//e2.  In  Figure  3,  for  example,  although  pl->q2 
and  ql->p2,  there  is  no  way  to  tell  whether  pi  or 
ql  comes  first;  they  may  be  concurrent. 

3.2.3  Enabling  Halation  ■> 


transmission.  Such  kind  of  properties  can  be  spec¬ 
ified  by  the  introduction  of  the  enabling  relation, 
denoted  by  "■>*  between  events.  Two  events,  say 
a  and  b,  satisfy  the  relation  a»b  if  the  exist¬ 
ence  of  event  a  will  cause  the  .ccurrence  of  event 
b  in  the  future.  The  relation  «»  has  Che  fol¬ 
lowing  properties: 

(1)  Events  are  enabled  in  the  future, 
if  a  ■>  b  then  a  ->  b 

(2)  Anti -symmetry  property, 

if  a  ■»  b  then  *  (b  ->  a) 

(3)  Irreflexivity  property, 

’  (a  ■>  a) 

(4)  Transitivity  property, 

if  a  •>  b  and  b  •>  c  then  a  »  c 

Properties  (2)  and  (3)  can  be  derived  from  (1)  and 
tha  properties  of  relation  ->  ,  while  (1)  and  (4) 
are  eeaential  axioms  for  the  relation  ->  , 

3.2.4  Syetem,  Environment,  Their  Interfaces 

and  Events 

The  event  apace  in  the  computation  history  is 
categorized  into  three  dietinct  domaina:  the  sys¬ 
tem,  tha  environment  and  tha  interfacial  ports. 

A  system  Interacts  with  its  environment  by 
exchanging  messages  through  unidirectional 
Interfaces  called  ports,  as  depicted  in  Figure  4. 

An  inport  loutport)  directs  messages  from  the  en¬ 
vironment  (system)  to  the  system  (environment) . 

Every  port  defines  sequences  of  interfacial 
events.  Every  event  in  a  port  history  is  uniquely 
identified  by  an  integer  number,  called  ordinal 
number^  Thus,  a  port  history  is  a  total  ordering 
of  events,  although  the  events  in  system  or  in 
environment  are  only  a  partial  ordering. 

4.  Tha  Language  EBS 

Based  on  the  concepts  above,  we  developed  a 
language  called  EBS  (Event  Baaed  specification 
language)  to  specify  tha  behavior  of  distributed 
systems.  Instead  of  presenting  tha  formal  syntax 
of  the  language,  we  use  examples  to  show  up  its 
expressive  power. 

4.1  ffvepple  1:  Reliable  Transmission  Systems 

A  reliable  transmission  system  (RT)  is  one 
through  which  messages  are  transmitted  without 
error,  loss,  duplication  or  reordering  from  an 
inport  to  an  outpore  (see  Figure  5) .  Although  most 
physical  cosszunication  madia  are  unreliable  that 
may  lose,  duplicate  or  reorder  mssssges,  almost 
all  designer!  provide  coassunication  protocols  (e.g. 
Alternate  Bit  Protocol)  to  convert  them  into  logi¬ 
cally  reliable  ones  for  the  ease  of  application 
programs  that  build  on  the  top  of  the  comuni- 
cation  systems. 


An  important  class  of  properties  in  coenuni- 
cation  systems  is  the  guaranteed  service  of  message 
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The  property  that  there  is  no  loss  of  massages 
during  ths  transmission  means  that  every  message 
ssnt  from  ths  inport  A  will  eventually  bs  trans¬ 
mitted  to  the  outport  B.  This  can  ba  spscifisd  as 
follows: 


(*  RT11  (A,B)  [1]  :  So  loss  of  messages*) 

V  A  |  b*  B 
a->  b; 


Similarly,  ths  propsrty  that  massages  at  B  ara  not 
ganaratad  intamally  or  externally  but  ara  anablad 
cy  msssagas  at  X,  is  spscifisd  as  follows: 


(*  RT12(A,B):  no  self-existing  msssagas*) 
V  b-  B  *  a-  A 
a»>  bj 


(• 

*) 


RT13(A,B):  no  internally  or  externally 
generated  massages 

W  be  B,  se  SYS,  **•  ENV  {2] 

(s  «>b  t>  )  A  a«»s«>b)  * 

(e  «>b  •>  )  «»  X  o->a->b) 


which  says  that  the  receiving  and  sending  event 
carry  the  same  massage  contents. 

These  are  about  the  weakest  properties  that 
a  reliable  transmission  system  should  have.  A 
very  good  feature  of  this  kind  of  orthogonal  speci¬ 
fication  is  that  a  specification  can  be  easily 
adapted  to  different  applications.  For  example , 
if  we  want  to  specify  the  behavior  of  a  communi¬ 
cation  system  which  not  only  transmits  messages 
reliably  but  also  performs  code  conversions 
between  computer  systems  communicating  with  each 
other  using  different  codes  (a.g.,  ASCII  and 
EBCDIC) ,  we  need  only  change  RT21  to 

{#  TR21(A,B>:  message  transformer*) 

V  a- A,  b-  B 

a->  b  #»  b.msg-  F(a.msg) 

where  F  is  the  code  conversion  function,  and  leave 
others  unchanged.  This  can  also  be  seen  from  the 
specification  of  the  following  system. 

4.2  Example  2:  Unreliable  Tra-  emission  System  (IT) 


The  reserved  werd  SYS  (ENV)  refers  to  the  set  of 
system  (environment)  events.  The  property  that 
there  is  no  duplication  of  messages  is  specified 
as  follows: 

(*  RT14(A,B):  no  duplication  of  messages  *) 

V  «-  A,  bl.b2«-  B 

a«>bl  *  a->b2  #>  bl!b2 

which  says  that  every  sending  event  can  only  en¬ 
able  a  unique  receiving  event.  The  property  that 
the  order  of  messages  is  preserved  after  trans¬ 
mission  is  specified  as  follows: 

(*  RT15 (A,B) :  no  out  of  order  messages  ») 

V  al,a2*  A,  bl ,b2—  B 
al-»bl  *  a2-»b2 

#>  (al->  a2  *  bl-»  b2)  v 
(all  e2  *  bll  b2)  v 
(a2->  al  *  b2->  bl) 

which  says  that  if  al  is  sent  before  a2  then  it 
will  *leo  lie  received  before  a2.  The  property 
that  the  contents  of  messages  are  preserved  after 
the  transmission  is  specified  as  follows: 

(*  RT21 (A, 8) :  preservation  of  massage 
contents*) 

V  a*  A,  b*  B 

a*>b  #>  a.msgwb.msg 

(1]  He  will  use  RT11  to  nasw  this  property  after¬ 
wards  for  convenience. 

12)  The  order  of  operator  precedence  in  the  lan¬ 
guage  is  as  follows:  (1)  uniary  operators; 
v  (for  all) ,  (there  exists)  and  *  (logical 
not) ;  (2)  relational  operators :  ♦  (belongs  to) 

-  (equivalent  to) ,  B  (equals  to) »  (3) 
logical  operators:  v  (logical  or) ,  *  (logical 
•nd) | (4)  #>  (logical  Implication) . 


An  unreliable  transmission  system  is  the  one 
through  which  massages  may  be  lost,  duplicated 
or  reordered,  but  there  is  a  non-zero  probability 
of  message  transmission  and  no  erroneous  massages. 
Most  physical  coammnication  media  belong  to  this 
clsss. 

The  property  that  "here  is  a  nou-zero  proba¬ 
bility  of  massage  transmission  can  be  specified 

as 

(*NZ(A,B) :  a  nonzero  probability  of  success¬ 
ful  message  transmission. 

*) 

V  ai~  A 

(V  aj»-  A  aj.msg-  ai.msg 

#>  )•  ak*-  A  aj->  ak  *  ak.msg-  ai.msg) 
#>  (}••<■  A,  b*-  B 

a»>  b*  a.msgw  ai.msg  *  ai->  a) 

which  means  that  if  a  group  of  massages  having  the 
same  contents  are  sent  unboundedly  than  at  least 
one  of  them  will  reach  B. 

The  unreliable  transmission  system  is  speci¬ 
fied  as  follows: 

System  OT  (A  :  inport; 

B  :  outport)  ; 

Behavior 

(*  A  nonzero  probability  of  successful 

massage  transsdssion. 

•) 

NZ (A,B)  ; 

(*  No  self-existing  messages  *) 

RT12 (A,  B); 


.  <*.A  >:  * 
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(*  No  internally  or  externally  generated 
messages  *) 

RT13 (A,  B); 

(*  RT11,  RT14  and  RT1S  are  discarded 
which  means  that  the  system  may 
lose,  duplicate  or  reorder  messages. 

•) 

(•No  erroneous  messages  •) 

RT21(A,  3) i 

End  behavior 
End  system. 

5.  Structure  Specification  and  Verification 

In  a  top-down  hierarchical  design,  the  service 
that  a  distributed  system  provides  is  described 
first  by  the  behavior  specification.  Then  the 
specification  is  decomposed,  according  to  a 
design  rationale,  into  a  set  of  sub- systems 
cosnunicating  via  the  service  of  connection  links. 
He  call  such  kind  of  design  (internal)  descrip¬ 
tion  of  a  system,  its  structure  specification. 

Once  we  get  both  behavior  and  structure  l paci¬ 
fies  tione  ,  the  correctness  of  a  design  can  be 
proved  by  checking  the  consistency  between  these 
two  specifications. 

3.1  System  Constructs 

A  subsystem  is  a  building  block  of  the  whole 
system.  The  computation  of  a  subsystem  is  de¬ 
scribed  by  a  behavior  specification,  which  can  be 
further  decomposed  into  a  structure  specification. 
In  this  way,  our  specification  technique  sup¬ 
ports  the  hierarchical  design  methodology. 

*  connects  an  outport  of  a  subsystem  to 

an  in port  of  another  subsystem,  when  two  ports 
are  linked,  they  are  merged  into  a  single  port. 

The  event  semantics  of  a  link  are  that  ports  are 
identical  in  the  outport  and  the  inport  being 
linked  together.  By  identical  we  mean  two  events 
are  just  the  same,  it  is  impossible  to  distinguish 
between  them. 

Not*  that  a  link  is  different  from  a  reliable 
transmission  system  in  that  the  letter  introduces 
finite  message  delay  as  in  a  physical  cable  con¬ 
nection  while  the  former  transmits  massages  reli¬ 
ably  aad  without  any  delay  (i.a. ,  Instantaneously) . 
Note  alee  that  two  ports  cannot  be  linked  unless 
they  have  exactly  the  seme  neeeege  types. 

3.2  Exammla  3i  A  Tandem  Network 

In  pmoket-switched  network,  a  packet  of 
meeaege,  instead  of  sent  directly  from  the  source 
node  to  the  destination  node  uaing  a  long-haul 
transmission  line,  is  passed  vie  some  intermediate 
nodes  between  tha  source  node  and  the  destination 
node.  A  neeeege  is  sent  reliably  from  the  source 
node  to  the  intermediate  node  end  then  sent  reli¬ 
ably  from  the  intermediate  node  to  the  destination 
node.  Thus,  the  structure  of  the  communication 


system  can  be  considered  as  consists  of  s  sat  of 
reliable  transmission  sub-systems  connecting  in 
series,  which,  as  a  whole,  provides  tha  service 
of  a  reliable  transmission  system  for  the  users 
of  this  pecket-  switched  network.  We  call  such  a 
sarial  connection  of  two  or  more  subsystems,  a 
tandem  (see  Figure  6)  network. 

5.2.1  Verification  of  the  Tandem  Network 

Sines  wo  era  uaing  tha  same  mathematically 
sound  notations  (i.a.,  first-order  logic  and  par¬ 
tial  ordering  relations) ,  the  verification  process 
can  be  carried  out  as  proving  theorems. 

Thaoram  1.  A  tandem  connection  of  two  reliable 

systems  behaves  as  a  single  reliable  one. 

Proof 

The  no  loss  property  can  be  proved  as  follows: 

(1)  For  all  p  in  PA  there  is  a  q  in  PB 
such  that  p->  q  (Since  RTll  of  SA) 

(2)  For  all  r  in  PC  there  is  an  s  in  PD 
such  that  r»>  s  (sines  RT11  of  SB) 

(3)  Let  q—  r  (since  PB  and  PC  are  connected) 

(4)  P”»  s  (since  “>  is  transitive) 

Other  properties  can  be  proved  similarly,  indepen¬ 
dent  of  on#  another. 

Although  the  proofs  of  the  theorems  are 
carried  out  in  e  somehow  informal  way,  they  may 
actually  be  formalized.  See  [CHE82]  for  details 
of  tha  verification. 

5.3  Example  4:  An  Alternate-Bit  Protocol 

An  Alternate-Bit  Protocol  is  intended  to  pro¬ 
vide  s  reliable  message  transfer  over  an  unreliable 
transmission  medium  from  a  fixed  sender  or  a  fixed 
receiver.  The  service  provided  by  this  protocol 
is,  thus,  nothing  mors  than  that  of  a  reliable 
transmission  system. 

Tha  undar lying  communication  medium  is  an 
unreliable  one,  which  may  lose,  duplicate  or 
reorder  massages,  however,  there  is  a  non-zero 
probability  of  successful  massage  tr an amission. 

3.3.1  Structure  Specification  of  An  Alternate- 

Bit  Protocol 

To  guarantee  a  maasaga  tent  from  one  end  to 
be  received  finally  at  the  other  end,  we  should 
taka  advantage  of  tha  property,  “non-zero  proba¬ 
bility  of  massage  transmission,"  of  the  unreliable 
■edits.  The  idea  ia  that  tha  Sender  keep  on  send¬ 
ing  the  same  massage  unboundedly  until  it  gats 
back  an  acknowledgement  from  the  Receiver,  and 
tha  Receiver  acknowledges  all  swssagas  received. 

To  avoid  duplication  of  massages,  a  sarial 
(integer)  nvaber,  as  a  unique  id,  is  attached  to 
each  massage  sent  by  tha  Sander  and  tha  Receiver 
accepts  messages  only  if  their  sarial  numbers  have 
never  appeared  before.  To  avoid  reordering  mes¬ 
sages,  we  sequsntlalise  tha  sending  of  the  message 


by  requiring  that  tha  sandar  cannot  sand  a  aacond 
massage  until  tha  previous  one  has  been  acknowl¬ 
edged. 

Tha  key  ideas  can  be  specified  formally  in  EBS 
as  follows: 

(*  Alternate-Bit  Protocol  *) 


unreliable  one:  it  is  possible  that  the  acknowl¬ 
edgement  may  be  lost,  accordingly.  Fortunately, 
it  can  be  proved  that  if  the  SS  sends  the  same 
massages  unboundedly,  though  DM  is  unreliable, 
unbounded  messages  will  arrive  at  RS.  Since  RS 
acknowledges  all  messages  received,  it  is  guar¬ 
anteed  that  at  least  one  acknowledgement  will 
arrive  at  SS. 


Sender : 

t'  Guaranteed  message  transmission:  keep 
on  sanding  the  same  message 
unboundedly  until  get  back  an  acknowl¬ 
edgement.  ') 

V  ip  *  IP 

(f  da*  OS  ip«  ds)  * 

(($•  ar*  AR  ar.msgno*  ord(ip))  v 
(V  dl*  OS  ip-»  dl 

#>  *  d2*  OS  ip»>  d2'dl->d2) ) ; 

('Sequence  Control:  do  not  send  a  new 
massage  until  all  previous  ones  are 
acknowledged.  *) 

V  ip*-  IP 
(V  k*  N 

k>  ord(ip) 

#>  t  ar  ♦  AR  ar.msgno  •  k  * 
ar  ->ip) i 

(*  Contents  of  massages:  send  out  a 
message  together  with  a  serial  number 
as  a  unique  id. 

') 

V  ip  *  IP,  ds  *  DS 

ip  «>  ds  *>  ip.msg  -  ds.data  * 
ds.msgno  »  ord  (ip) 

Receiver 

(•  Send  acknowledgement  for  every  mes¬ 
sage  received  back  to  the  Sender.  •) 

V  Ar*-  DS  )•  as—  AS 
'r->  as: 

('send  back  the  serial  number  as  an 
acknowledgement  of  receipt.  *) 

V  dr  *  DR,  as  *  AS 

DR  «>  as  *>  as.msgno  - 
dr.msgno; 

(•  Accept  those  messages  that  never 
cosm  before.  *) 

V  dr  »  DR, 

(  }  op*  OP  dr  «>  op) 

♦»  ■(  )  dr'*  DR 
dr'->  dr  * 

dr'. segno*  dr.msgno) ; 

5,3.2  Verification  of  an  Alternate-Bit 
Protocol 

Ns  want  to  prove  that  tha  structure  specifi¬ 
cation  of  this  Alternate-Bit  Protocol  meets  its 
behavior  specification.  Since  the  OH  (Data 
Transmission  Media)  is  an  unreliable  one,  the  SS 
(Send  station)  has  to  send  the  massages  unboundedly 
to  guarantee  that  at  least  one  will  reach  tha  RS 
Receive  Station)  finally.  However,  since  the  AM 
(Acknowledgement  Transmission  Medium)  is  also  an 


Theorem  2.  If  the  underlying  communication  medium 
has  a  non-zero  probability  of  message  trans¬ 
mission,  then  if  an  unbounded  number  of 
messages  having  tha  same  contents  are  sent 
from  A,  then  not  only  one  but  an  unbounded 
number  of  massages  will  arrive  at  B. 

Proof  By  mathematical  induction:  Since  unbounded 
number  of  massages  having  the  same  contents 
are  sent  from  IP,  at  least  one  of  them,  say 
x,  will  reach  OP.  Since  the  number  of  mes¬ 
sages  after  x  is  again  unbounded,  at  least 
one  of  them  will  arrive  OP.  The  same  process 
goes  on  and  on. 

Theorem  3.  The  Alternate-Bit  Protocol  makes  an 
unreliable  system  behave  as  a  reliable  one. 

Proof  Based  on  Theorem  2,  the  no  loss  property 
is  easy  to  prove.  Other  properties  can  be 
proved  one  by  one  in  a  way  similar  to  the 
proofs  in  tha  tandem  network. 

See  [CHE821  for  details  of  the  formal  speci¬ 
fication  and  tha  verification  of  the 
Alternate-Bit  Protocol. 

6.  Comparisons  with  Other  Current  Approaches 

6.1  Temporal  logic  Approaches 

Temporal  logic,  first  introduced  by  Pnulin 
as  an  adaption  of  a  classical  logic  suitable  for 
defining  the  semantics  of  computer  programs,  is 
used  in  specifying  and  verifying  concurrent 
systems  [OWI80] . 

Several  properties  of  concurrent  systems  can 
be  stated  using  two  temporal  operations:  E3 
(henceforth)  and  ^  (eventually) .  However,  global 
invariants  that  should  be  true  throughout  the 
computation,  rather  than  merely  input/output  rela¬ 
tions,  are  stated  as  the  behavior  specification 
of  a  distributed  system.  Though  Invariants  facil¬ 
itate  implementation  verification,  they  are  diffi¬ 
cult  to  specify,  understand  and  are  less  intuitive 
than  input-output  relations  from  the  user's  view¬ 
point,  as  tha  behavior  specification  in  EBS. 

6.2  Trace  Approaches 

The  notion  of  traces  is  used  in  the  speci¬ 
fications  and  verifications  of  networks  of 
processes  by  Misra  t  chandy  [HIS81],  and  Zhoa 
Hoars  [ZK081] ,  There  are  several  deficiencies  in 
the  trace  approach.  First,  since  notations  for 
sequences  are  used  exclusively,  trace  speci¬ 
fications  are  awkward  in  expressing  properties 
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whose  data  structures  are  not  well-defined  se¬ 
quences.  Typical  examples  are  those  properties 
of  unreliable  transmission  systems  that  may  lose, 
duplicate  and  reorder  messages.  Second,  the 
'liveness*  properties  such  as  eventual  deadlock, 
or  eventual  termination,  etc.,  are  in  general  not 
specified  and  verified  using  the  trace  notion 
directly. 

In  comparison,  events  in  EBS  are  only  par¬ 
tially  ordered)  no  assumption  of  the  existence 
of  a  global  clock  is  made.  The  concept  of  events 
is  more  elementary  than  that  of  traces  (sequences 
of  events);  consequently,  some  properties  that  can 
be  specified  in  IBS  easily  can  only  be  expressed 
in  traces  with  difficulty.  The  "liveness"  prop¬ 
erties  can  be  specified  directly  by  the  enabling 
relation  ■»  in  EBS. 

7.  Conclusions 

In  summary,  both  the  behavior  and  struc¬ 
tural  specifications  based  on  event  model  are 
(1)  formal:  using  partial  ordering  relations 
and  first  order  predicate  calculus;  (2)  minimal: 
orthogonal  properties  are  specified  separately 

(3)  extensible:  new  requirements  can  be  added 
without  changing  the  original  specification;  and 

(4)  complete :  most  interesting  properties  in 
distributed  systems  can  be  specified. 

The  correctness  of  a  design  can  be  proved 
before  implementation  by  checking  the  consis¬ 
tency  between  the  behavior  specification  and 
structure  specification  of  a  system.  Important 
properties  of  concurrent  systems  including  both 
’safety"  properties  and  "liveness"  properties 
can  be  specified  and  verified. 

Moreover,  since  the  specification  technique 
defines  the  orthogonal  properties  of  a  system 
separately,  each  of  them  can  be  verified  inde¬ 
pendently.  Thus,  the  proof  technique  avoids  the 
exponential  state-explosion  problem  found  in 
state-machine  specification  techniques. 

In  addition  to  having  the  most  desirable  fea¬ 
tures  of  a  specification  technique,  EBS  represents 
time  concept  by  a  partial  ordering  relation  of 
events  and  represents  concurrency  by  the  lacking 
of  ordering  between  events.  This  makes  EBS  more 
accurate  a  model  for  distributed  systems,  which 
are  inherently  concurrent,  asynchronous,  and  non- 
da termini Stic. 
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